Automatic object model generation

ABSTRACT

A target device, such as a storage controller, may host an interface that manages objects, such as storage objects (e.g., logical unit numbers (LUNs), volumes, etc.), maintained by the storage controller. Accordingly, an object on the storage controller may be modeled as an object model, such as an object oriented library, based upon modeling information mined from the storage controller. The object model may be automatically generated, such as by discovering the interface to the object using available information in a command line interface (CLI) and/or an XML file (e.g., an XML help file). In this way, the object model may use hosted/exported interfaces to manage the object.

BACKGROUND

A developer may deploy product code on a client device, such asdeployment of product code for a storage application on a storagecontroller. The storage controller may comprise a storage applicationprogramming interface (API) configured to execute commands related tostorage objects managed by the product code. The developer may attemptto run test code against the product code on the storage controller,such as test code to create a volume storage object. The test code mayutilize test libraries, such as object oriented libraries, to accessand/or interact with the product code and the storage API in order tocreate the volume storage object. Such test libraries are manuallycreated based upon the product code. For example, a test librarydeveloper may read documentation for the storage API in order toidentify functionality of the storage API, such as a create volumeobject method having a volume name attribute and a volume sizeattribute. In this way, the test library developer may manually generatea test library for the create volume object method, which may involve anextensive amount of manual resources or time, and may delay thedeveloper of the test code that will utilize the test library. When achange occurs to the product code on the storage controller, the testlibrary may be unusable until the test library is manually updated, andthus future testing may be delayed until the test library is updated.

DESCRIPTION OF THE DRAWINGS

FIG. 1 is a component block diagram illustrating an example clusterednetwork in accordance with one or more of the provisions set forthherein.

FIG. 2 is a component block diagram illustrating an example data storagesystem in accordance with one or more of the provisions set forthherein.

FIG. 3 is a flow chart illustrating an exemplary method of automaticallygenerating an object model for an object.

FIG. 4A is a component block diagram illustrating an exemplary systemfor automatically generating an object model for an object.

FIG. 4B is a component block diagram illustrating an exemplary systemfor updating an object model based upon a command call.

FIG. 5 is a component block diagram illustrating an exemplary system forproviding remote access to perform a command, associated with an object,on a target device.

FIG. 6 is a flow chart illustrating an exemplary method of automaticallygenerating an object oriented library for an object.

FIG. 7 is a component block diagram illustrating an exemplary system forautomatically generating an object oriented library for an object.

FIG. 8 is a component block diagram illustrating an exemplary system forproviding remote access to perform a command, associated with an object,on a storage controller.

FIG. 9 is an example of a computer readable medium in accordance withone or more of the provisions set forth herein.

DETAILED DESCRIPTION

Some examples of the claimed subject matter are now described withreference to the drawings, where like reference numerals are generallyused to refer to like elements throughout. In the following description,for purposes of explanation, numerous specific details are set forth inorder to provide an understanding of the claimed subject matter. It maybe evident, however, that the claimed subject matter may be practicedwithout these specific details. Nothing in this detailed description isadmitted as prior art.

An object model, such as an object oriented library, may beautomatically generated for an object (e.g., a storage object, such as avolume) so that test code may utilize the object model to remotelyperform commands associated with the object (e.g., resize a volume on astorage controller). In an example, the object model is automaticallygenerated in real-time, such as during runtime of the test code, whichmay mitigate unnecessary and/or costly references to a source treeassociated with the object (e.g., a source tree of a user interfaceand/or API used to managed objects, such as volumes). In an example, theobject model may comprise one or more methods used to manipulate anobject, such as a rename method or a delete method. The object model maybe generated by accessing a target device, such as the storagecontroller, and evaluating an interface (e.g., a volume commandinterface) to identify modeling information about the object (e.g.,methods and/or attributes for volumes). In this way, the object modelmay be created based upon the modeling information. The object model mayprovide remote access to perform commands, related to the object, on thetarget device.

To provide context for automatically generating an object model for anobject, FIG. 1 illustrates an embodiment of a clustered networkenvironment 100. It may be appreciated, however, that the techniques,etc. described herein may be implemented within the clustered networkenvironment 100, a non-cluster network environment, and/or a variety ofother computing environments, such as a desktop computing environment.That is, the instant disclosure, including the scope of the appendedclaims, is not meant to be limited to the examples provided herein. Itwill be appreciated that where the same or similar components, elements,features, items, modules, etc. are illustrated in later figures but werepreviously discussed with regard to prior figures, that a similar (e.g.,redundant) discussion of the same may be omitted when describing thesubsequent figures (e.g., for purposes of simplicity and ease ofunderstanding).

FIG. 1 is a block diagram illustrating an example clustered networkenvironment 100 that may implement at least some embodiments of thetechniques and/or systems described herein. The example environment 100comprises data storage systems 102 and 104 that are coupled over acluster fabric 106, such as a computing network embodied as a privateInfiniband or Fibre Channel (FC) network facilitating communicationbetween the storage systems 102 and 104 (and one or more modules,component, etc. therein, such as, nodes 116 and 118, for example). Itwill be appreciated that while two data storage systems 102 and 104 andtwo nodes 116 and 118 are illustrated in FIG. 1, that any suitablenumber of such components is contemplated. Similarly, unlessspecifically provided otherwise herein, the same is true for othermodules, elements, features, items, etc. referenced herein and/orillustrated in the accompanying drawings. That is, a particular numberof components, modules, elements, features, items, etc. disclosed hereinis not meant to be interpreted in a limiting manner.

It will be further appreciated that clustered networks are not limitedto any particular geographic areas and can be clustered locally and/orremotely. Thus, in one embodiment a clustered network can be distributedover a plurality of storage systems and/or nodes located in a pluralityof geographic locations; while in another embodiment a clustered networkcan include data storage systems (e.g., 102, 104) residing in a samegeographic location (e.g., in a single onsite rack of data storagedevices).

In the illustrated example, one or more clients 108, 110 which maycomprise, for example, personal computers (PCs), computing devices usedfor storage (e.g., storage servers), and other computers or peripheraldevices (e.g., printers), are coupled to the respective data storagesystems 102, 104 by storage network connections 112, 114. Networkconnection may comprise a local area network (LAN) or wide area network(WAN), for example, that utilizes Network Attached Storage (NAS)protocols, such as a Common Internet File System (CIFS) protocol or aNetwork File System (NFS) protocol to exchange data packets.Illustratively, the clients 108, 110 may be general-purpose computersrunning applications, and may interact with the data storage systems102, 104 using a client/server model for exchange of information. Thatis, the client may request data from the data storage system, and thedata storage system may return results of the request to the client viaone or more network connections 112, 114.

The nodes 116, 118 on clustered data storage systems 102, 104 cancomprise network or host nodes that are interconnected as a cluster toprovide data storage and management services, such as to an enterprisehaving remote locations, for example. Such a node in a data storage andmanagement network cluster environment 100 can be a device attached tothe network as a connection point, redistribution point or communicationendpoint, for example. A node may be capable of sending, receiving,and/or forwarding information over a network communications channel, andcould comprise any device that meets any or all of these criteria. Oneexample of a node may be a data storage and management server attachedto a network, where the server can comprise a general purpose computeror a computing device particularly configured to operate as a server ina data storage and management system.

As illustrated in the exemplary environment 100, nodes 116, 118 cancomprise various functional components that coordinate to providedistributed storage architecture for the cluster. For example, the nodescan comprise a network module 120, 122 (e.g., N-Module, or N-Blade) anda data module 124, 126 (e.g., D-Module, or D-Blade). Network modules120, 122 can be configured to allow the nodes 116, 118 to connect withclients 108, 110 over the network connections 112, 114, for example,allowing the clients 108, 110 to access data stored in the distributedstorage system. Further, the network modules 120, 122 can provideconnections with one or more other components through the cluster fabric106. For example, in FIG. 1, a first network module 120 of first node116 can access a second data storage device 130 by sending a requestthrough a second data module 126 of a second node 118.

Data modules 124, 126 can be configured to connect one or more datastorage devices 128, 130, such as disks or arrays of disks, flashmemory, or some other form of data storage, to the nodes 116, 118. Thenodes 116, 118 can be interconnected by the cluster fabric 106, forexample, allowing respective nodes in the cluster to access data on datastorage devices 128, 130 connected to different nodes in the cluster.Often, data modules 124, 126 communicate with the data storage devices128, 130 according to a storage area network (SAN) protocol, such asSmall Computer System Interface (SCSI) or Fiber Channel Protocol (FCP),for example. Thus, as seen from an operating system on a node 116, 118,the data storage devices 128, 130 can appear as locally attached to theoperating system. In this manner, different nodes 116, 118, etc. mayaccess data blocks through the operating system, rather than expresslyrequesting abstract files.

It should be appreciated that, while the example embodiment 100illustrates an equal number of N and D modules, other embodiments maycomprise a differing number of these modules. For example, there may bea plurality of N and/or D modules interconnected in a cluster that doesnot have a one-to-one correspondence between the N and D modules. Thatis, different nodes can have a different number of N and D modules, andthe same node can have a different number of N modules than D modules.

Further, a client 108, 110 can be networked with the nodes 116, 118 inthe cluster, over the networking connections 112, 114. As an example,respective clients 108, 110 that are networked to a cluster may requestservices (e.g., exchanging of information in the form of data packets)of a node 116, 118 in the cluster, and the node 116, 118 can returnresults of the requested services to the clients 108, 110. In oneembodiment, the clients 108, 110 can exchange information with thenetwork modules 120, 122 residing in the nodes (e.g., network hosts)116, 118 in the data storage systems 102, 104.

In one embodiment, the data storage devices 128, 130 comprise volumes132, which is an implementation of storage of information onto diskdrives or disk arrays or other storage (e.g., flash) as a file-systemfor data, for example. Volumes can span a portion of a disk, acollection of disks, or portions of disks, for example, and typicallydefine an overall logical arrangement of file storage on disk space inthe storage system. In one embodiment a volume can comprise stored dataas one or more files that reside in a hierarchical directory structurewithin the volume.

Volumes are typically configured in formats that may be associated withparticular storage systems, and respective volume formats typicallycomprise features that provide functionality to the volumes, such asproviding an ability for volumes to form clusters. For example, where afirst storage system may utilize a first format for their volumes, asecond storage system may utilize a second format for their volumes.

In the example environment 100, the clients 108, 110 can utilize thedata storage systems 102, 104 to store and retrieve data from thevolumes 132. In this embodiment, for example, the client 108 can senddata packets to the N-module 120 in the node 116 within data storagesystem 102. The node 116 can forward the data to the data storage device128 using the D-module 124, where the data storage device 128 comprisesvolume 132A. In this way, in this example, the client can access thestorage volume 132A, to store and/or retrieve data, using the datastorage system 102 connected by the network connection 112. Further, inthis embodiment, the client 110 can exchange data with the N-module 122in the host 118 within the data storage system 104 (e.g., which may beremote from the data storage system 102). The host 118 can forward thedata to the data storage device 130 using the D-module 126, therebyaccessing volume 132B associated with the data storage device 130.

It may be appreciated that in one example, one or more object modelingcomponents for automatically generating object models and/or one or morecommand execution components for using object models to implementcommands for objects on target devices may be implemented within theclustered network environment 100. For example, an object modelingcomponent and/or a command execution component may be hosted by client108 and/or client 110, and may model objects and/or perform commands onobjects stored by node 116 and/or node 118.

FIG. 2 is an illustrative example of a data storage system 200 (e.g.,102, 104 in FIG. 1), providing further detail of an embodiment ofcomponents that may implement one or more of the techniques and/orsystems described herein. The example data storage system 200 comprisesa node 202 (e.g., host nodes 116, 118 in FIG. 1), and a data storagedevice 234 (e.g., data storage devices 128, 130 in FIG. 1). The node 202may be a general purpose computer, for example, or some other computingdevice particularly configured to operate as a storage server. A client205 (e.g., 108, 110 in FIG. 1) can be connected to the node 202 over anetwork 216, for example, to provides access to files and/or other datastored on the data storage device 234.

The data storage device 234 can comprise mass storage devices, such asdisks 224, 226, 228 of a disk array 218, 220, 222. It will beappreciated that the techniques and systems, described herein, are notlimited by the example embodiment. For example, disks 224, 226, 228 maycomprise any type of mass storage devices, including but not limited tomagnetic disk drives, flash memory, and any other similar media adaptedto store information, including, for example, data (D) and/or parity (P)information.

The node 202 comprises one or more processors 204, a memory 206, anetwork adapter 210, a cluster access adapter 212, and a storage adapter214 interconnected by a system bus 242. The storage system 200 alsoincludes an operating system 208 installed in the memory 206 of the node202 that can, for example, implement a Redundant Array of Independent(or Inexpensive) Disks (RAID) optimization technique to optimize areconstruction process of data of a failed disk in an array.

The operating system 208 can also manage communications for the datastorage system, and communications between other data storage systemsthat may be in a clustered network, such as attached to a cluster fabric215 (e.g., 106 in FIG. 1). Thus, the host 202 can respond to clientrequests to manage data on the data storage device 234 (e.g., oradditional clustered devices) in accordance with these client requests.The operating system 208 can often establish one or more file systems onthe data storage system 200, where a file system can include softwarecode and data structures that implement a persistent hierarchicalnamespace of files and directories, for example. As an example, when anew data storage device (not shown) is added to a clustered networksystem, the operating system 208 is informed where, in an existingdirectory tree, new files associated with the new data storage deviceare to be stored. This is often referred to as “mounting” a file system.

In the example data storage system 200, memory 206 can include storagelocations that are addressable by the processors 204 and adapters 210,212, 214 for storing related software program code and data structures.The processors 204 and adapters 210, 212, 214 may, for example, includeprocessing elements and/or logic circuitry configured to execute thesoftware code and manipulate the data structures. The operating system208, portions of which are typically resident in the memory 206 andexecuted by the processing elements, functionally organizes the storagesystem by, among other things, invoking storage operations in support ofa file service implemented by the storage system. It will be apparent tothose skilled in the art that other processing and memory mechanisms,including various computer readable media, may be used for storingand/or executing program instructions pertaining to the techniquesdescribed herein. For example, the operating system can also utilize oneor more control files (not shown) to aid in the provisioning of virtualmachines.

The network adapter 210 includes the mechanical, electrical andsignaling circuitry needed to connect the data storage system 200 to aclient 205 over a computer network 216, which may comprise, among otherthings, a point-to-point connection or a shared medium, such as a localarea network. The client 205 (e.g., 108, 110 of FIG. 1) may be ageneral-purpose computer configured to execute applications. Asdescribed above, the client 205 may interact with the data storagesystem 200 in accordance with a client/host model of informationdelivery.

The storage adapter 214 cooperates with the operating system 208executing on the host 202 to access information requested by the client205. The information may be stored on any type of attached array ofwriteable media such as magnetic disk drives, flash memory, and/or anyother similar media adapted to store information. In the example datastorage system 200, the information can be stored in data blocks on thedisks 224, 226, 228. The storage adapter 214 can include input/output(I/O) interface circuitry that couples to the disks over an I/Ointerconnect arrangement, such as a storage area network (SAN) protocol(e.g., Small Computer System Interface (SCSI), iSCSI, hyperSCSI, FiberChannel Protocol (FCP)). The information is retrieved by the storageadapter 214 and, if necessary, processed by the one or more processors204 (or the storage adapter 214 itself) prior to being forwarded overthe system bus 242 to the network adapter 210 (and/or the cluster accessadapter 212 if sending to another node in the cluster) where theinformation is formatted into a data packet and returned to the client205 over the network connection 216 (and/or returned to another nodeattached to the cluster over the cluster fabric 215).

In one embodiment, storage of information on arrays 218, 220, 222 can beimplemented as one or more storage “volumes” 230, 232 that are comprisedof a cluster of disks 224, 226, 228 defining an overall logicalarrangement of disk space. The disks 224, 226, 228 that comprise one ormore volumes are typically organized as one or more groups of RAIDs. Asan example, volume 230 comprises an aggregate of disk arrays 218 and220, which comprise the cluster of disks 224 and 226.

In one embodiment, to facilitate access to disks 224, 226, 228, theoperating system 208 may implement a file system (e.g., write anywherefile system) that logically organizes the information as a hierarchicalstructure of directories and files on the disks. In this embodiment,respective files may be implemented as a set of disk blocks configuredto store information, whereas directories may be implemented asspecially formatted files in which information about other files anddirectories are stored.

Whatever the underlying physical configuration within this data storagesystem 200, data can be stored as files within physical and/or virtualvolumes, which can be associated with respective volume identifiers,such as file system identifiers (FSIDs), which can be 32-bits in lengthin one example.

A physical volume, which may also be referred to as a “traditionalvolume” in some contexts, corresponds to at least a portion of physicalstorage devices whose address, addressable space, location, etc. doesn'tchange, such as at least some of one or more data storage devices 234(e.g., a Redundant Array of Independent (or Inexpensive) Disks (RAIDsystem)). Typically the location of the physical volume doesn't changein that the (range of) address(es) used to access it generally remainsconstant.

A virtual volume, in contrast, is stored over an aggregate of disparateportions of different physical storage devices. The virtual volume maybe a collection of different available portions of different physicalstorage device locations, such as some available space from each of thedisks 224, 226, and/or 228. It will be appreciated that since a virtualvolume is not “tied” to any one particular storage device, a virtualvolume can be said to include a layer of abstraction or virtualization,which allows it to be resized and/or flexible in some regards.

Further, a virtual volume can include one or more logical unit numbers(LUNs) 238, directories 236, qtrees 235, and files 240. Among otherthings, these features, but more particularly LUNS, allow the disparatememory locations within which data is stored to be identified, forexample, and grouped as data storage unit. As such, the LUNs 238 may becharacterized as constituting a virtual disk or drive upon which datawithin the virtual volume is stored within the aggregate. For example,LUNs are often referred to as virtual drives, such that they emulate ahard drive from a general purpose computer, while they actually comprisedata blocks stored in various parts of a volume.

In one embodiment, one or more data storage devices 234 can have one ormore physical ports, wherein each physical port can be assigned a targetaddress (e.g., SCSI target address). To represent respective volumesstored on a data storage device, a target address on the data storagedevice can be used to identify one or more LUNs 238. Thus, for example,when the host 202 connects to a volume 230, 232 through the storageadapter 214, a connection between the host 202 and the one or more LUNs238 underlying the volume is created.

In one embodiment, respective target addresses can identify multipleLUNs, such that a target address can represent multiple volumes. The I/Ointerface, which can be implemented as circuitry and/or software in thestorage adapter 214 or as executable code residing in memory 206 andexecuted by the processors 204, for example, can connect to volume 230by using one or more addresses that identify the LUNs 238.

It may be appreciated that in one example, one or more object modelingcomponents for automatically generating object models and/or one or morecommand execution components for using object models to implementcommands for objects on target devices may be implemented within network216 or any other type of network (e.g., a home network, a corporatenetwork, a first device connected to second device using a cable or awireless connection, etc.). For example, an object modeling componentand/or a command execution component may be hosted by client 205, andmay model objects and/or perform commands on objects stored by node 202.

One embodiment of automatically generating an object model for an objectis illustrated by an exemplary method 300 of FIG. 3. At 302, the methodstarts. A target device, such as a storage controller (e.g., nodes116/118 of FIG. 1 and/or node 202 of FIG. 2), may host an interfaceassociated with an object. The interface may comprise a command lineinterface, an application programming interface (API), and/or any othertype of interface associated with objects, such as storage objects(e.g., a volume object, a logical unit number (LUN) object, a directoryobject, a storage protocol object, a communication object, an objectoriented programming object, and/or any other type of data object). Theinterface may expose various functionality for managing objects, such asa create object method, a delete object method, a modify object method,and/or attributes associated with such methods (e.g., a name attribute,a size attribute, an owner attribute, etc.).

At 304, the target device may be accessed for automatic modeling of theobject managed by the interface. In an example, the object may bedynamically modeled at runtime in response to identifying a command callassociated with the object (e.g., responsive to a test code developerissuing a create volume command call from a device, a volume object onthe target device may be modeled to create a volume object model thatmay be used to facilitate performance of a create volume command on thetarget device). In an example, the target device may be remotely loggedinto, such as by the device used by the test code developer.

At 306, the interface may be evaluated to identify modeling informationassociated with the object. The modeling information may comprise amethod invokable for the object (e.g., a create, delete, resize, rename,backup, snapshot creation, restore, and/or other methods for the volumeobject) and/or attributes utilized by such methods (e.g., a nameattribute, a size attribute, etc.). In an example, instructional helpinformation provided by the interface may be parsed to identify themodeling information (e.g., a “/help” command may be issued to a commandline interface in order to receive instructional help information thatmay be parsed to identify methods and/or attributes supported by thecommand line interface for the object). In another example, a fileassociated with the interface (e.g., a help xml file used by theinterface to provide instructional help information) may be parsed toidentify the modeling information, such as a parameter, a parametertype, a privilege level, a return type, a description, and/or othermodeling information specified by the file. In another example, a sourcetree of an application on the target device (e.g., a source tree for anapplication that provides the interface) may be referenced to identifythe modeling information (e.g., the source tree may be referenced toidentify paths to files, such as xml files, comprising command or methoddefintions supported for the object, such as a build root$build_root/final/image/mroot/help/help_xml/ for a help xml file).

At 308, an object model for the object is created based upon themodeling information. In an example, the object model is dynamicallycreated during runtime of test code (e.g., a command call comprisingtest instructions) that is to access the target device to testfunctionality associated with the object (e.g., a delete volume method).In an example, the object model may be an abstract representation of theobject, as opposed to a logical equivalent. In an example, the objectmodel may not represent a local object, but may provide remote access tomanipulate the object or an element thereof that is owned and/or managedby the target device (e.g., a device may be provided with remote access,through the object model, to an object on a storage controller). Thatis, the object model may provide remote access to perform a command,associated with the object, on the target device. In an example, theobject model comprises an object orientated library that models theobject. The object oriented library may specify a method and/orattributes of the method invokable for the object (e.g., a create volumemethod comprising a name attribute and a size attribute). In an example,the object model may be annotated with additional functionality for theobject (e.g., a change owner method comprising a prior owner attributeand a new owner attribute).

In an example, a command call may be received from a device (e.g., adevice remote from the target device). The command call may correspondto a method for the object (e.g., a create volume method). The objectmodel may be used to translate the command call into a target API formatused by an API on the target device (e.g., a volume management API),resulting in a translated command call. The translated command call maybe used to invoke (e.g., remotely invoke from the device) the API on thetarget device to perform the method. In this way, the object model maybe utilized to perform commands for an object on the target device.

In an example of creating the object model, the object model may beincrementally created and/or updated with modeling information basedupon what methods are requested by command calls. For example, an emptynamespace package may be created for the object (e.g., created on adevice remote to the target device). Responsive to receiving a firstcommand call for the object (e.g., a resize volume command call receivedfrom the device), the object model may be created to comprise a firstmethod definition for a first method associated with the first commandcall (e.g., a resize volume method may be included within the objectmodel). The empty namespace package may be populated with the objectmodel to create a populated namespace package. Responsive to receiving asecond command call for the object (e.g., a rename command call receivedfrom the device), the object model within the populated namespacepackage may be updated to comprise a second method definition for asecond method associated with the second command call (e.g., a renamevolume method may be included within the object model). In this way, theobject model may be updated with methods as such methods are requestedby command calls, which may mitigate unnecessary and/or costlyreferences to the interface on the target device. At 310, the methodends.

FIG. 4A illustrates an example of a system 400 for automaticallygenerating an object model 418 for an object. A target device 402 maycomprise a user interface 406, such as a command line interface, and/ora storage object API 404 configured to manage an object, such as a LUNobject. The storage object API 404 may provide create objectfunctionality, delete object functionality, resize object functionality,and/or other functionality. The user interface 406 may be associatedwith a source tree 410 that may provide location information (e.g., apath) for modeling information, such as a help.xml file 408 used by theuser interface 406 to provide instruction help information 422.

The system 400 may comprise an object modeling component 416. The objectmodeling component 416 may be configured to access 412 the target device402 to obtain object modeling information 414. For example, the objectmodeling component 416 may evaluate the storage object API 404, the userinterface 406, the source tree 410, the help.xml file 408, and/or theinstructional help information 422 to identify the object modelinginformation 414. The object modeling component 416 may create the objectmodel 418 based upon the modeling information 414. For example, objectmodeling component 416 may populate the object model 418 with a createobject method 420 comprising a name attribute, a size attribute, anowner attribute, and/or other attributes derived from the modelinginformation 414 about the create object method 420. In an example, theobject model 418 may be annotated with additional functionality for theobject, such as a method or an attribute (e.g., a security annotationattribute for the create object method 420). In an example, the modelinginformation 414 and/or the object model 418 may correspond to the createobject method 420 (e.g., but not a delete object method or a resizeobject method) because a command call from a device may have requestedremote access to the target device 402 to perform the create objectmethod 420. The object model 418 may be updated based upon command callsrequesting remote access to the target device 402 to perform othermethods, such as a delete object method (e.g., FIG. 4B).

FIG. 4B illustrates an example of a system 450 for updating an objectmodel 418 based upon a command call. In an example, the object model 418may have been created by an object modeling component 416 for an objecton a target device 402 (e.g., FIG. 4A). Responsive to receiving acommand call to remotely access the target device 402 to perform adelete object method, the object modeling component 416 may access 452the target device 402 to identify modeling information 454 associatedwith the object, such as a delete object method 418 (e.g., delete objectfunctionality provided by a storage object API 404). The object modelingcomponent 416 may update the object model 418 to comprise the deleteobject method 456 derived from the modeling information 454. In thisway, the command call may utilize the object model 418 to remotelyaccess the target device 402 in order to invoke a create object method420 and/or the delete object method 456 on the target device 402, suchas by invoking the storage object API to invoke correspondingfunctionality (e.g., FIG. 5).

FIG. 5 illustrates an example of a system 500 for providing remoteaccess to perform a command, associated with an object, on a targetdevice 402. In an example, an object model 418 may have been created byan object modeling component 416 (e.g., FIG. 4A and 4B). The system 500may comprise a command execution component 506 that has access to theobject model 418 (e.g., the command execution component 506 and/or theobject model 418 may be hosted on a device 502, and may be configured toprovide remote access from the device 502 to the target device 402). Acommand call 504 may be received from the device 502. The command call504 may correspond to a method for an object modeled by the object model418, such as a create object method 504. The command execution component506 may utilize the object model 418 to translate the command call 504(e.g., from a format understandable to the device 502, such as anARM-based instruction) into a target API format used by an API on thetarget device 402, resulting in a translated command call 508. Forexample, the command execution component 506 may identify a createobject method definition within the object model 418. The create objectmethod definition may specify one or more attributes utilized by acreate object method 420 (e.g., FIG. 4A), which may be implemented by astorage object API 404 on the target device 402. Accordingly, thecommand execution component 506 may format the command call 504according to the create object method definition that corresponds to anAPI format used by the storage object API 404. The command executioncomponent 506 may use the translated command call 508 to invoke thestorage object API 404 to perform the create object method 420 (e.g.,FIG. 4A).

One embodiment of automatically generating an object oriented libraryfor an object is illustrated by an exemplary method 600 of FIG. 6. At602, the method starts. At 604, a storage controller hosting a userinterface associated with an object may be accessed (e.g., a storagecontroller interface may provide command line access to manage logicalunit numbers (LUNs) stored within one or more storage devices managed bythe storage controller). A 606, the user interface may be evaluated toidentify modeling information associated with the object (e.g., a helpfile, defining methods, attributes, and/or other descriptive informationfor LUNs, may be parsed to identify the modeling information). Themodeling information may comprise a method definition for a methodassociated with the object (e.g., a resize LUN method). The methoddefinition may specify an attribute used by the method (e.g., a LUN nameattribute, a LUN size attribute, etc.).

At 608, an object orientated library, such as an object model, for theobject may be created based upon the modeling information. The objectoriented library may provide remote access to perform a command,associated with object, on the storage controller (e.g., a device mayutilize the object oriented library to remotely access the storagecontroller to perform a resize LUN command). In an example, a commandcall corresponding to the method definition may be received from adevice (e.g., the command call may be formatted according to the device,such as an instruction set, a processor instruction type, or protocolused by the device). At 610, the object oriented library may be used totranslate the command call into a target API format used by an API onthe storage controller to create a translated command call. At 612, thetranslated command call may be used to invoke the API on the storagecontroller to perform the method. In this way, the command call, such astest code, may be executed against the storage controller utilizing theobject orientated library created on the fly during runtime of the testcode. At 614, the method ends.

FIG. 7 illustrates an example of a system 700 for automaticallygenerating an object oriented library 718 for an object. A storagecontroller 702 may comprise a user interface 706, such as a command lineinterface, and/or a volume object API 704 configured to manage anobject, such as a volume object. The volume object API 704 may providecreate volume object functionality, delete volume object functionality,resize volume object functionality, and/or other functionality. The userinterface 706 may be associated with a source tree 710 that may providelocation information (e.g., a path) for modeling information, such as ahelp.xml file 708 used by the user interface 706 to provide instructionhelp information 722.

The system 700 may comprise an object modeling component 416. The objectmodeling component 416 may be configured to access 712, such as logginginto, the storage controller 702 to obtain object modeling information714. For example, the object modeling component 416 may evaluate thevolume object API 704, the user interface 706, the source tree 710, thehelp.xml file 708, and/or the instructional help information 722. Theobject modeling component 416 may create the object oriented library 718based upon the modeling information 714. For example, object modelingcomponent 416 may populate the object oriented library 718 with a createvolume method 720 comprising a volume name attribute, a volume sizeattribute, a volume owner attribute, and/or other attributes derivedfrom the modeling information 714 about the create volume method 720. Inan example, the object oriented library 718 may be annotated withadditional functionality for the volume object, such as a method or anattribute (e.g., a migration volume method having a source locationattribute and a destination location attribute). In an example, themodeling information 714 and/or the object oriented library 718 maycorrespond to the create volume method 720 (e.g., but not a deletevolume method or a resize volume method) because a command call from adevice may have requested remote access to the storage controller 720 toperform the create volume method.

FIG. 8 illustrates an example of a system 800 for providing remoteaccess to perform a command, associated with an object, on a storagecontroller 702. In an example, an object oriented library 718 may havebeen created by an object modeling component 416 (e.g., FIG. 7). Thesystem 800 may comprise a command execution component 506 that hasaccess to the object oriented library 718 (e.g., the command executioncomponent 506 and/or the object oriented library 718 may be hosted on adevice 802, and may be configured to provide remote access from thedevice 802 to the storage controller 702). A command call 804 may bereceived from the device 802. The command call 804 may correspond to amethod for a volume object modeled by the object oriented library 718,such as a create volume method 720. The command execution component 506may utilize the object oriented library 718 to translate the commandcall 804 (e.g., from a format understandable to the device 502, such asan ARM-based instruction) into a target API format used by a volumeobject API 704 on the storage controller 702, resulting in a translatedcommand call 808. For example, the command execution component 506 mayidentify a create volume method definition within the object orientedlibrary 718. The create volume method definition may specify one or moreattributes utilized by the create volume method 720 (e.g., FIG. 7),which may be implemented by the volume object API 704 on the storagecontroller. Accordingly, the command execution component 506 may formatthe command call 804 according to the create volume method definitionthat corresponds to an API format used by the volume object API 704. Thecommand execution component 506 may use the translated command call 808to invoke the volume object API 704 to perform the create volume method(e.g., FIG. 7).

Still another embodiment involves a computer-readable medium comprisingprocessor-executable instructions configured to implement one or more ofthe techniques presented herein. An example embodiment of acomputer-readable medium or a computer-readable device that is devisedin these ways is illustrated in FIG. 9, wherein the implementation 900comprises a computer-readable medium 908, such as a CD-R, DVD-R, flashdrive, a platter of a hard disk drive, etc., on which is encodedcomputer-readable data 906. This computer-readable data 906, such asbinary data comprising at least one of a zero or a one, in turncomprises a set of computer instructions 904 configured to operateaccording to one or more of the principles set forth herein. In someembodiments, the processor-executable computer instructions 904 areconfigured to perform a method 902, such as at least some of theexemplary method 300 of FIG. 3 and/or at least some of the exemplarymethod 600 of FIG. 6, for example. In some embodiments, theprocessor-executable instructions 904 are configured to implement asystem, such as at least some of the exemplary system 400 of FIG. 4A, atleast some of the exemplary system 450 of FIG. 4B, at least some of theexemplary system 500 of FIG. 5, at least some of the exemplary system700 of FIG. 7, and/or at least some of the exemplary system 800 of FIG.8, for example. Many such computer-readable media are contemplated tooperate in accordance with the techniques presented herein.

It will be appreciated that processes, architectures and/or proceduresdescribed herein can be implemented in hardware, firmware and/orsoftware. It will also be appreciated that the provisions set forthherein may apply to any type of special-purpose computer (e.g., filehost, storage server and/or storage serving appliance) and/orgeneral-purpose computer, including a standalone computer or portionthereof, embodied as or including a storage system. Moreover, theteachings herein can be configured to a variety of storage systemarchitectures including, but not limited to, a network-attached storageenvironment and/or a storage area network and disk assembly directlyattached to a client or host computer. Storage system should thereforebe taken broadly to include such arrangements in addition to anysubsystems configured to perform a storage function and associated withother equipment or systems.

In some embodiments, methods described and/or illustrated in thisdisclosure may be realized in whole or in part on computer-readablemedia. Computer readable media can include processor-executableinstructions configured to implement one or more of the methodspresented herein, and may include any mechanism for storing this datathat can be thereafter read by a computer system. Examples of computerreadable media include (hard) drives (e.g., accessible via networkattached storage (NAS)), Storage Area Networks (SAN), volatile andnon-volatile memory, such as read-only memory (ROM), random-accessmemory (RAM), EEPROM and/or flash memory, CD-ROMs, CD-Rs, CD-RWs, DVDs,cassettes, magnetic tape, magnetic disk storage, optical or non-opticaldata storage devices and/or any other medium which can be used to storedata.

Although the subject matter has been described in language specific tostructural features or methodological acts, it is to be understood thatthe subject matter defined in the appended claims is not necessarilylimited to the specific features or acts described above. Rather, thespecific features and acts described above are disclosed as exampleforms of implementing at least some of the claims.

Various operations of embodiments are provided herein. The order inwhich some or all of the operations are described should not beconstrued to imply that these operations are necessarily orderdependent. Alternative ordering will be appreciated given the benefit ofthis description. Further, it will be understood that not all operationsare necessarily present in each embodiment provided herein. Also, itwill be understood that not all operations are necessary in someembodiments.

Furthermore, the claimed subject matter is implemented as a method,apparatus, or article of manufacture using standard programming orengineering techniques to produce software, firmware, hardware, or anycombination thereof to control a computer to implement the disclosedsubject matter. The term “article of manufacture” as used herein isintended to encompass a computer program accessible from anycomputer-readable device, carrier, or media. Of course, manymodifications may be made to this configuration without departing fromthe scope or spirit of the claimed subject matter.

As used in this application, the terms “component”, “module,” “system”,“interface”, and the like are generally intended to refer to acomputer-related entity, either hardware, a combination of hardware andsoftware, software, or software in execution. For example, a componentincludes a process running on a processor, a processor, an object, anexecutable, a thread of execution, a program, or a computer. By way ofillustration, both an application running on a controller and thecontroller can be a component. One or more components residing within aprocess or thread of execution and a component is localized on onecomputer or distributed between two or more computers.

Moreover, “exemplary” is used herein to mean serving as an example,instance, illustration, etc., and not necessarily as advantageous. Asused in this application, “or” is intended to mean an inclusive “or”rather than an exclusive “or”. In addition, “a” and “an” as used in thisapplication are generally be construed to mean “one or more” unlessspecified otherwise or clear from context to be directed to a singularform. Also, at least one of A and B and/or the like generally means A orB or both A and B. Furthermore, to the extent that “includes”, “having”,“has”, “with”, or variants thereof are used, such terms are intended tobe inclusive in a manner similar to the term “comprising”.

Many modifications may be made to the instant disclosure withoutdeparting from the scope or spirit of the claimed subject matter. Unlessspecified otherwise, “first,” “second,” or the like are not intended toimply a temporal aspect, a spatial aspect, an ordering, etc. Rather,such terms are merely used as identifiers, names, etc. for features,elements, items, etc. For example, a first set of information and asecond set of information generally correspond to set of information Aand set of information B or two different or two identical sets ofinformation or the same set of information.

Also, although the disclosure has been shown and described with respectto one or more implementations, equivalent alterations and modificationswill occur to others skilled in the art based upon a reading andunderstanding of this specification and the annexed drawings. Thedisclosure includes all such modifications and alterations and islimited only by the scope of the following claims. In particular regardto the various functions performed by the above described components(e.g., elements, resources, etc.), the terms used to describe suchcomponents are intended to correspond, unless otherwise indicated, toany component which performs the specified function of the describedcomponent (e.g., that is functionally equivalent), even though notstructurally equivalent to the disclosed structure. In addition, while aparticular feature of the disclosure may have been disclosed withrespect to only one of several implementations, such feature may becombined with one or more other features of the other implementations asmay be desired and advantageous for any given or particular application.

1-21. (canceled)
 22. A method comprising: receiving, by a storageserver, a command call for an object; creating, by the storage server,an empty namespace package for the received object based on the commandcall; identifying, by the storage server, based on the command call,modeling data associated with the object; creating, by the storageserver, an object model for the object based on the modeling data; andpopulating, by the storage server, the empty namespace package with theobject model to create a populated namespace package, wherein thepopulated object model comprises a definition associated with thecommand call.
 23. The method of claim 22, further comprising: parsing,by the storage server, an xml file associated with the received object,wherein the identifying the model data is based on the parsed xml file.24. The method of claim 22, further comprising: referencing, by thestorage server, source tree data in an application on a target computingdevice, wherein the identifying the model data is based on thereferenced source tree data.
 25. The method of claim 24, furthercomprising: receiving, by the storage server, a subsequent command call;translating, by the storage server, based on the object model, thesubsequent command call into a target application programming interface(API) format; and invoking, by the storage server, the API on the targetcomputing device based on the translated subsequent command call. 26.The method of claim 22, further comprising: accessing, by the storageserver, a remote computing device, wherein the remote computing devicehosts an interface associated with the object and the identifying isfurther based on the interface associated with the object.
 27. Themethod of claim 22, wherein the object model is dynamically created atruntime.
 28. A computing device comprising: a memory containing amachine readable medium comprising machine executable code having storedthereon instructions for performing a method of generating an objectmodel; a processor coupled to the memory, the processor configured toexecute the machine executable code to cause the processor to: receive acommand call for an object; create an empty namespace package for thereceived object based on the command call; identify, based on thecommand call, modeling data associated with the object; create an objectmodel for the object based on the modeling data; and populate the emptynamespace package with the object model to create a populated namespacepackage, wherein the populated object model comprises a definitionassociated with the command call.
 29. The device of claim 28, whereinthe processor is further configured to execute programmed instructions,which comprise the programmed instructions stored in the memory to:parse an xml file associated with the received object, wherein theidentifying the model data is based on the parsed xml file.
 30. Thedevice of claim 28, wherein the processor is further configured toexecute programmed instructions, which comprise the programmedinstructions stored in the memory to: reference source tree data in anapplication on a target computing device, wherein the identifying themodel data is based on the referenced source tree data.
 31. The deviceof claim 30, wherein the processor is further configured to executeprogrammed instructions, which comprise the programmed instructionsstored in the memory to: receive a subsequent command call; translate,based on the object model, the subsequent command call into a targetapplication programming interface (API) format; and invoke the API onthe target computing device based on the translated subsequent commandcall.
 32. The device of claim 28, wherein the processor is furtherconfigured to execute programmed instructions, which comprise theprogrammed instructions stored in the memory to: access a remotecomputing device, wherein the remote computing device hosts an interfaceassociated with the object and the identifying is further based on theinterface associated with the object.
 33. The device of claim 28,wherein the object model is dynamically created at runtime.
 34. Anon-transitory machine readable medium having stored thereoninstructions for performing a method comprising machine executable codewhich when executed by at least one machine, causes the machine to:receive a command call for an object; create an empty namespace packagefor the received object based on the command call; identify, based onthe command call, modeling data associated with the object; create anobject model for the object based on the modeling data; and populate theempty namespace package with the object model to create a populatednamespace package, wherein the populated object model comprises adefinition associated with the command call.
 35. The medium of claim 34,further having stored thereon instructions for performing a methodcomprising machine executable code which when executed by at least onemachine causes the machine to: parse an xml file associated with thereceived object, wherein the identifying the model data is based on theparsed xml file.
 36. The medium of claim 34, further having storedthereon instructions for performing a method comprising machineexecutable code which when executed by at least one machine causes themachine to: reference source tree data in an application on a targetcomputing device, wherein the identifying the model data is based on thereferenced source tree data.
 37. The medium of claim 36, further havingstored thereon instructions for performing a method comprising machineexecutable code which when executed by at least one machine causes themachine to: receive a subsequent command call; translate, based on theobject model, the subsequent command call into a target applicationprogramming interface (API) format; and invoke the API on the targetcomputing device based on the translated subsequent command call. 38.The medium of claim 34, further having stored thereon instructions forperforming a method comprising machine executable code which whenexecuted by at least one machine causes the machine to: access a remotecomputing device, wherein the remote computing device hosts an interfaceassociated with the object and the identifying is further based on theinterface associated with the object.
 39. The medium of claim 34,wherein the object model is dynamically created at runtime.